Explanations of the Patent Claims 



Claims 31, 33, 34, 37-43 and Claim 53 are cancelled. 

Claims 28-30, 32, 35, 36 and 44-52 are amended and reasons given. 

In the claims, insertions are underlined words and deletions are in bold typeface within 
square brackets []. 

The following explanations clarify the novelty, inventive steps and industrial 
applicability of this invention and claims. To avoid confusion in terminology such as 
"Data Identification Number", "Index Number", "PIN", "Card Identification Number" 
and "Account Number", here are the definitions of terms used in my application and the 
explanation: 

Each Multi- Application Card (MAC) has a number. This is referred to in the claim as a 
"data identification number" and in explanations as a "MAC identification number". 
The MAC identification number is read from the MAC by a card reader device. 

Each MAC corresponds to a record in a database. Each record in the database (whose 
key is the MAC Identification Number) contains sub-records; each sub-record is 
locatable by the MAC identification number and an Index Number, also referred to as a 
Card Identification Number (CIN). The Index Number, typically a 4-digit number, is 
physically entered at a data entry device such as a keypad. 

Most credit and debit card users are familiar with the use of a Person al Identification 
Number (PIN), which has served to identify the owner of a debit card. A PIN is also 
typically a 4-digit number, physically entered at a data entry device such as a keypad. 

NOTE: Card industry research found that OVER 90% OF CARD OWNERS USE 
THE SAME PIN FOR ALL THEIR DEBIT, CHECK, ATM AND CONVENIENCE 
CARDS. This is logical because a PIN identifies the person, not the card. CREDIT 
CARDS ARE SIGNATURE-VERIFIED AND DO NOT USE PINS. 

In my invention, each sub-record within the group referred to (in claims 28 and 50) as a 
"first subset" of index numbers identifies (or contains, or points to) a single account 
number. The account number could be a credit card number, a debit card number, 
driver's license number, etc. Each sub-record within the group referred to (in claims 29 
and 51) as the "second subset" of index numbers contains (or points to) a Lock code 
instead of an account number. Each sub-record within the group referred to (in claims 30 
and 52) as the "third subset" of index numbers contains (or points to) an Unlock code, 
instead of an account number or a Lock code. 

Here are the steps involved in using my invention: 

1 . The multi-application card (MAC) is read at a card reader. The card reader reads 
the MAC identification number. 



2 



2. As when using a debit card, the user is asked to physically enter a number in the 
keypad. The user manually enters a number (called an Index Number or Card 
Identification Number), typically a 4-digit number. 

3. The MAC Number and the Index Number are sent from the point-of-service to the 
card translator system. Using the MAC number, the translator locates a record in its 
database. The index number (or Card Identification Number) is used to find a sub- 
record (or entry) within the record. If, as the claim reads, the index number is within 
the first subset of index numbers (i.e. the sub-record identifies or contains an account 
number), that account number is retrieved and processing continues. The account 
number could be a credit card number, a debit card number or some other account 
number. If the index number is within the second subset of index numbers (i.e. the 
sub-record identifies or contains a Lock code instead of an account number), the 
entire record is flagged as "locked" or "disabled". The MAC can no longer be used 
to access an account number from the database until the lock flag is removed. If the 
index number is within the third subset of index numbers (i.e. the sub-record 
identifies or contains an Unlock code instead of an account number or Lock code), 
the Lock flag for the record is removed, effectively "unlocking" or "re-enabling" the 
MAC. 



Re: US Patent 5,770,843 (ROSE et al): 

In contrast to my invention, here's how the ROSE system works: 

1 . The multi-application card (MAC) is swiped at a card reader. The card reader 
reads the MAC identification number. That's where the similarity ends. 

2. The MAC number is sent to the remote system. It reads the record, searches all the 
sub-records (or entries) for account numbers in the record and displays ALL accounts 
on a screen for the user to select one. 

3. With all accounts on the MAC displayed - before having to enter anything - the 
user chooses one of the accounts, e.g. a Bank of America (BofA) Debit card. 

4. The system now asks for the PIN of the BofA Debit card. The user enters the PIN 
for the BofA Debit card at a data entry device. 

5. The PIN is sent to the remote system. If the PIN (which can be the same for ALL 
the accounts) matches that of the BofA Debit card, the transaction is allowed to 
proceed. 

Differences between ROSE and the current Invention: 

Here are important differences between my invention and that of ROSE et al.: 

1 . ROSE uses PINs, which (in over 90% of cases) are found to be the same for all 
accounts of a card owner, while my invention uses Index Numbers which must 
be unique for each account, enforcing better security. 
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2. ROSE discloses to a potential thief ALL the accounts on a MAC record by merely 
swiping the MAC at a point-of-service terminal - even before the user is asked to 
enter anything. As a result, any user (including a thief) could never make a 
mistake in selecting an account - because ALL accounts are shown and the user 
selects from among them. If there are 5 accounts on the MAC, in the ROSE 
invention, only 5 accounts are displayed and the user has 5 possible choices. In 
my invention (assuming 4 digits are used for the Index/CIN), there are 10,000 
possible numbers (0000 to 9999) that the user could enter. Of the 10,000 possible 
numbers, typically more than 99.9% would be incorrect. Only the owner would 
know what accounts are on the MAC and the unique Index Number pertaining to 
each account. 

3. Credit cards do not use PINs. In the ROSE system, if the MAC database uses the 
same PIN as the card issuer, a thief with a Multi-Application Card could simply 
swipe the MAC and select a credit card - which has no PIN - to use it. 

4. Let us assume the ROSE invention forces a PIN on all cards including credit 
cards. Again, the thief sees all the accounts on the MAC by merely swiping the 
MAC at a point-of-sale terminal. If the thief knows the PIN of any one card 
belonging to the MAC owner, inherent in the design and confirmed by industry 
statistics, the thief could almost certainly use all the accounts on the MAC. 
Ironically, the ROSE invention would help a thief by displaying all the card 
accounts on the MAC, by simply swiping it at a point of sale. My invention 
requires the user to enter the index/CIN of a valid card account without displaying 
what accounts are on the MAC. Even if the MAC owner uses the PIN of a card as 
its index/CIN, a thief with one PIN could access only one account on the MAC. 

5. The ROSE invention requires multiple exchanges of messages between the card 
reader and the database to identify a specific account number. By using unique 
index numbers for each stored account, my invention requires just one exchange 
of messages to identify a specific account number. This is extremely important 
because even milliseconds matter when it comes to card authorization. 

6. The ROSE invention was designed for a kiosk; it requires a device that can 
display all accounts on the record so that a user can select from among them. My 
invention does not require such a device; it can use a standard debit card keypad. 

7. Changes in account numbers (whether in ROSE or my invention) would require a 
change to both databases - the card issuer database and the MAC database. 
However, in the ROSE invention - unless the MAC uses a different PIN from that 
in the card issuer database - a change in the PIN of any account would require a 
change in the database of the card issuer and also a change to the PIN in the MAC 
database. In my invention, changes to CINs and PINs are independent of each 
other. If the MAC owner changes the index number (or CIN) of an account, no 
change is required to the issuer database. If the MAC owner changes the PIN of a 
card, the only database needing the change is the issuer database. Since the MAC 
database in my invention does not use account PINs, no change is required to it. 

8. In the ROSE invention, it is NOT possible to identify an account number 
using the MAC Identification Number and the PIN because multiple 
accounts have the same PIN. In ROSE, the PIN is used to merely confirm a 
previously-selected (and already identified) account number. In my 
invention, the two data items, i.e. the MAC Identification Number and the 
Index, are sufficient to identify an individual account number. 

9. I believe use of the words "identify" and "single account number" in my claims 
differentiates this invention from ROSE. The Committee of 3 Examiners at the 
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European Patent Office (Euro. Pat. EP 1221 144) acknowledges the difference and 
so does the Canadian Intellectual Property Office. The USPTO Examiner of this 
application also acknowledges the difference and is seeking rewording of the 
claims to reflect the difference. Therefore, as in my Canadian patent application 
(CA 2,381,807, for which I now have a Notice of Allowance on 21 claims), I have 
amended my claims to state that the data identification number and the index 
number identify "a single account number", clearly different from the teachings of 
ROSE and PIERCE. The phrase "chosen by an/the authorized holder of the card 
device" has been deleted from claims 28-30 and 50-52. I trust these amendments 
meet with your approval. 



Differences between PIERCE and the current Invention: 

Here are important differences between my invention and that of PIERCE: 

1 . PIERCE describes a system that re-directs data from the retailer subsystem to the 
appropriate card issuer subsystem. The use of a card translator subsystem to 
translate (without additional input) an identification number and index 
number to a single account number is not in the teachings of either PIERCE 
or ROSE. 

2. The claims in this patent application point out, as shown in Figure 6 of the 
drawings, that a card translator (a subsystem to convert an identification number 
and index number to a single account number) may be located in, or connected to, 
a client/retailer subsystem, an issuer subsystem or an intermediate subsystem 
usually referred to in the industry as a card processor. 

3 . As stated earlier, I believe using the words "identify" and "single account 
number" in my claims differentiates this invention from ROSE and PIERCE. I 
have amended my claims to state that the data identification number and the index 
number identify a single account number, clearly different from the teachings of 
ROSE and PIERCE. The phrase "chosen by an/the authorized holder of the card 
device" has been deleted from claims 28-30 and 50-52. I trust these amendments 
meet with your approval. 
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